[보안] 파일 무결성 전자서명 검증

NOTE

배포 파일(펌웨어, SW 패치 등)의 위·변조 여부를 수신 측이 검증할 수 있도록 하는 전자서명(디지털 서명) 체계 — “사이드카(Detached Signature)” 방식 정리.

📌 개념

• 단순히 해시값 문자열을 비교하는 것은 무결성 검증이 아니다 — 공격자가 파일과 해시를 함께 조작하면 그대로 통과된다. 반드시 비대칭키(RSA 등) 전자서명을 써야 “이 파일이 신뢰된 발급자로부터 왔다”는 것까지 증명된다.
• 사이드카 방식: 원본 파일(firmware.zip)은 그대로 두고, 서명값만 별도 파일(firmware.zip.sig)로 만들어 원본과 같은 경로에 둔다. DB 스키마나 기존 전송 프로토콜을 변경하지 않고 무결성 검증을 추가할 수 있는 장점이 있다.

동작 절차

[배포 측 — 서명 생성]
1. RSA 키 쌍 생성 (개인키는 배포 측만 보관, 절대 외부 전달 금지)
2. 업로드 즉시 원본 파일 전체를 개인키로 서명 (예: SHA256withRSA)
   ※ 주의: SHA256withRSA는 내부적으로 해시까지 포함해서 서명하므로,
     "해시를 미리 계산해서 그 해시값을 다시 서명"하는 이중 해싱을 하지 않는다.
3. "<원본파일명>.sig" 사이드카 파일 생성 (algorithm/keyId/hash/signature 필드 포함)
4. 다운로드 시 원본 + .sig 를 함께 전달 (zip 번들 또는 별도 요청)

[수신 측 — 서명 검증]
1. 미리 내장된 공개키(Public Key) 보유
2. 원본 파일 + .sig 를 함께 읽어 서명 검증 수행
   ※ 주의: 해시를 직접 만들고 비교하지 말고, verify() 계열 API로 "서명 검증"을 한 번에 수행
3. 성공 → 설치 진행 / 실패 → 설치 중단, 감사로그에 결과 기록

📌 설계 결정 포인트

포인트	내용
요청 횟수 최소화	원본과 서명을 별도 요청으로 나누면(v1) 요청이 2회 필요하고 이력 처리가 이원화됨 → zip으로 묶어 한 번에 전송(v2)하면 단순해짐
하위호환	서명이 아직 없는 구버전 파일은 기존 방식(원본만 스트리밍)으로 그대로 처리하고, 신규 파일부터만 서명 번들을 적용하면 전환 비용이 줄어듦
키 발급 시 SAN 불필요	TLS 서버 인증서와 달리, 서명용 키는 호스트 검증이 아니라 “파일 출처/무결성” 검증이 목적이므로 SAN 값이 필요 없음
감사 로그	서명 검증 성공/실패 이력을 감사로그로 남겨야 사후 추적이 가능 (검증 주체가 클라이언트 로컬인 경우, 서버 측에는 이 결과가 별도로 수집되지 않을 수 있다는 점을 설계 시 인지해야 함)

관련 문서

• (Netty_TLS) Netty 파이프라인 SSL-TLS 적용 - One-way TLS 서버 인증 구성 정리 — 이 문서의 “키 발급 시 SAN 불필요” 항목이 직접 비교하는 TLS 서버 인증서 발급 절차(SAN 필요)를 다루는 자매 노트